GUI progress update (kovarex) This is a continuation of the last status report from FFF-269. As it might not be a surprise, the biggest bottleneck of the 0.17 release is the GUI. I like to believe, that we have learned a lot from the pitfalls of the collaborative creative process of GUI. This is the typical way we were redesigning the GUI: Two to three people started discussing what could be cool to change in the particular GUI. Some people randomly joined and left the ongoing discussion. Arguments to discard certain ideas have to be repeated over and over. Then the discussion is ended because of something. A week later people start talking again, most of them forgot most of the stuff, or were discussing it with different people, so they assume some details of the changes to be understood by everyone, while they aren't. They come to an agreement how it should be done. They have a random discussion about it a week later and figure out, they had completely different ideas about how it should be done, they just didn't articulate them precisely. Both are kind of angry to have to reopen and re-negotiate the subject again. Someone starts to implement the GUI, but half-way through it is uncovered, that there was another layer of misunderstanding when specifying how should the work be done, and we need to go to step 1 again and repeat. Since many GUIs are thought and worked on in parallel, these situations overlapped and amplified the problems of mixing things up in our heads about what we agreed on in which GUI. Luckily, we eventually figured out, that it can't be done like this, and since there is a lot of work in the GUI, we need to make a process. It goes like this: First, there is some general discussion about the GUI, all team members can share their ideas. kovarex + Twinsen sit alone in the office, and discuss for some time (can be hours), all the pros and cons of how things should be done, and make some agreement. Twinsen writes a detailed UX document about the GUI containing the structure, and more importantly the behaviour, in a detailed manner. Twinsen + kovarex discuss the UX document and propose changes until they agree on the final version. Albert + Aleš take the UX document and create a UI mockup based on it. kovarex + Twinsen + Albert agree on the UI mockup or propose changes. Someone is assigned to implement the GUI based on the UX document and UI mockup kovarex reviews that the implementation is correct and points out some inconsistencies that he can see. Part of this step is making sure, that we share as many GUI styles and code as possible across different GUIs. kovarex + Albert have a final look on the implementation and fix final details until they both agree that the screen is fully finished. Having the UX documents/UI mockups always available proved to be a huge time saver. Not only it helps us to solve the communication problems, we also don't have to remember and re-articulate decisions from some time ago as we can just open the document and see what we agreed on and instantly continue where we left off. A good part of this strict pipeline is that we now have better knowledge of the state of the work progress. These are the GUI screens that we hope to deliver for 0.17: .header_cell { text-align:center; font-weight: bold; } .finished { text-align:center; font-weight: bold; } .not_finished { text-align:center; font-weight: bold; } .finished_gui_table { border-spacing: 10px; } .finished_gui_table td { border: 1px; border-style:solid; padding: 5px; } General UX UX draft UX review UI mockup UI review Implementation draft Implementation review Final review Load map Save map Graphics settings Control settings Sound settings Interface settings Other settings Map generator Technology GUI Technology tooltip Recipe/item/entity tooltip Action bar Shortcut bar Train GUI Manage/Install mods Main screen chat Recipe explorer Character screen Menu structure New game Help overlay Chat icon selector Blueprint library You can see, that there is still a lot of to do, but the work tends to accelerate as more and more of the GUI layouts/tilesets/standards are being finalized and reused. The conclusion is that 0.17 experimental in January is possible, but it might be February as well :).

Hello, the office is slowly ramping back up after the Christmas and New year festivities.

It's the last Friday of 2018, and as such the last Friday Facts before the New year of 2019. We all hope everyone has had a great 2018, and looking forward to a lot more automation fun to come in 2019. Albert has produced a postcard for you all to share to give the year a good send-off.

New Fluid system 2 (Dominik) Hi Factorians, Here is Dominik, with an update on the fluids. This time it is pretty much finished so I can tell you facts instead of just speculations. You will find how the new algorithm will work and some new handy usability features. In FFF-260 I wrote about how it all started, why we are doing it and what the plan is. There was a huge response from you all and I want to thank everyone for their contributions. Let me apologise to redditors, as at the beginning I started responding on the forums and when I realized there is reddit too, there were too many comments for me to handle. The forum users produced many ideas on how the system could work. About third of them was a fluid teleportation, many where known but many were entirely new and interesting. What intrigued me was the large variety of backgrounds they came from - differents kinds of engineers (mechanical, CS, electrical, ...), mathematicians, physicists, and even people with real pipes hands on experience. I won’t go through them here, you can find them on the forums or reddit. There were two proposals on the forum though that were so good that they made it into the game - from quinor and TheYeast. Both of these proposals were very similar and kinda similar to the previous game logic. What it shares is that the mechanic still uses fluid physics simulation and volume in a pipe as a base for the movement calculation. As a result, not much changes on the first glance. What they add though is an emphasis on the fluid network update being independent on the current state (i.e. updating one pipe only depends on state from the last tick) and is therefore independent on evaluation order, which was one of the big pains of the old model that led to sometimes ridiculous junction behavior. Difference between these two was rather small - quinor’s version allowed perfect throughput with 3 passes over the fluidboxes (fluidbox is the thing managing fluids for entities, so I will talk about them), while Yeast’s one was 2 pass with ¼ throughput. What was outstanding though is that TheYeast, a physicist, supported the model with a nice theoretical background and what’s more, he made an amazing JS simulator to test and compare various modification of the model. Because that extra pass in quinor’s version was too high a price for the perfect throughput, I went with TheYeast’s two pass one. Since the old algorithm only used a single pass run by entities for the update, I first needed to overhaul the whole system to allow accommodating the new one. Going from one pass to two passes necessarily means higher complexity, so we made a big effort to optimize everything we could to make sure we will still end up faster than 0.16. Kovarex wrote about it in FFF-271.

Hello, we recieved a lovely holiday gift from Steam this week: The note reads: Happy Holidays! From the Steam Team The chocolates are delicious and do not seem to be lasting long...

Hello, a large part of the team is attending GDS , if you are in Prague and interested in Games, you are welcome to come as well.

Game Developers Session 2018 GDS 2018 will be taking place next week, running from Friday 7th to Saturday 8th. This year, like last year, we are silver sponsors of the event, which means you will see some Factorio branding around the event and in their official booklet. Part of the preparation on our side was to produce a nice graphical asset for their use, which you can see below: The image is an aesthetic composition to showcase the design and theme of the game and its elements (while not necessarily making logical sense), and also contains the first public display of our new official Wube Software logo. About half the office team here will be attending the event, so if you are also going you might bump into us.

Steam Awards (Klonan) Steam has opened up the nominations for this years Steam Awards. Last year Factorio was actually selected as a nominee for the 'Haunts My Dreams' award. There is a category this year for 'Best Developer', and many in the community have wanted to nominate us for that category. Unfortunately to be eligible, we would need to have a developer page set up on Steam. We had some discussions, and decided to wait until we have a final 'Wube Software' logo and theme finalized before setting up a developer page. This means you won't be able to vote for us as best developer this year... This doesn't meant that you can't nominate Factorio for one of the categories, and there has already been some discussion on the subreddit about which games people are voting for.

Roadmap update (kovarex) A lot of people have been asking recently, when can they expect a new release and when is the game going to be finished. The original plan was to finish everything, and release the final version of Factorio ideally before the end of 2018. This was the plan at the beginning of the year. We worked in our usual way of "it is done when it is done" for quite some time, but then it started taking a little bit too long, and we weren't even sure what is a realistic timeframe to finish it in. To help this issue, we tried to become a little more organized in the past few weeks. We went through our list of all the development tasks, and tried to finalize it. We removed all the things that we decided to cut, and added all the missing things that we need to do before the game is finished. Then we tried to make some kind of time estimate for each task, to get a general idea of when everything will be finished. We started to be more conscious of who is working on what, and how much time each task is taking, to know how accurate the estimates are. The result was, that if it all goes well, we could be done in 6-9 months. This is probably not something you wanted to hear. After a few rounds of discussions, we decided split the releases of 0.17 and 0.18 in the following way: 0.17 plan It will contain all the things we have done up to this point, mainly: New render backend, which helps performance and solves a lot of issues (FFF-251) The graphical updates: walls, gates, turrets, belts, biters, spawners, electric poles (FFF-268, FFF-228, FFF-253) The GUI reskin (FFF-243) New map editor (FFF-252) Resource generation overhaul (FFF-258) Robot construction tools (FFF-255) Rich text (FFF-237, FFF-267) And more... It will also include some things we know we can finish soon enough, mainly: Redoing some of the most important GUIs (Action bar, character screen, main game GUI, train GUI, play GUI, tooltips) Fluid optimisations And several smaller things, which depends on how it goes We will release this during January 2019, we will announce it more precisely in advance. 0.18 plan It will become the final 1.0 version once it is stable. It will contain mainly: New tutorial New campaign Final mini tutorials Revision of rest of the GUI All remaining high res graphics graphics and final polish We obviously don't know exactly when is it going to be ready, but we hope it to be sooner than 9 months from now.

The modern biter (Albert, Ernestas) Besides vegetable and plant stuff, biters are the main population on the surface of the Factorio planet. They are the locals, and somehow, from a twisted perspective, they can even be considered the bad guys. Not anymore. The magic of high resolution gives us the chance to move deeper into their conceptualisation and we've added a new ingredient to their formulation: cute...-ish. For the last couple of weeks Ernestas and I have been working on the new version of the biters. Together we worked on developing the concept and ideas behind them, and Ernestas was doing the rest: modeling, texturing, shading, rigging, skinning, animating, rendering, post-processing, and being patient with me and my constant comments and changes. Cute is how we like them, we want you to feel sorry about planning massive biter massacres. In fact we want you to feel pity towards them, especially when you are killing them and destroying their habitat at industrial scale. But also we want you to be disgusted by them, because they are alien to you, and they need to look the part, so it is quite a complicated equation. Basically after the experience in-game with the classic version, we've learned what aspects of the biters are working well, and how to improve the parts which aren't. So we've decided to elongate their legs and accent their eyes in order to provide this more insectoid feeling. Also their new design is optimized for their attacks, they have 2 stronger front legs for providing destruction, 4 back legs to be able to run and stand during the attack, and stronger articulated mandibles to chew on your factories. In these animations we can fully see the potential of disgust, the way they move now is more insect-like, similar to a cockroach (many people are disgusted by cockroaches), and also we've balanced the animation loop with their speed in the game, so they shouldn't slide around. Keep in mind that this is still a work-in-progress and we have some more tweaks to do and extra animations to make, like their attack and death. We are also working on their sound design, and apart from that we might have some other surprises to make killing them extra gratifying to watch.